It is common in the prior art to have a family of programs and data that are intertwined in their relationship and their execution, such that a high rate of switching is essential among the different programs and there is shared use of the data bases in the family. Such a family of programs and data are often supported by a software subsystem (operating under an operating system). The subsystem often handles a large number of transactions that are concurrently accessing a large number of different programs and data bases in the family. For example, the concurrent transactions of banking tellers (both humans and machines) in a multi-branch banking complex may concurrently use deposit programs and withdrawal programs (that share the same data base, i.e. customer accounts), credit check programs and their data bases, and numerous other related banking programs and data bases, which are being accessed concurrently by a set of transaction programs invoked by individual requests for service.
Such a family of programs and data have been found to be usable at their fastest potential rate when they are all in a single address space (AS) being accessed from one or more CPUs. However, subsequent experience has indicated significant failures in the execution of such programs, due to incorrect store operations by any executing program wiping out part of another or a data base. Such execution failures have temporarily terminated the operation of a multi-branch banking business dependent on such a system. A programming system failure that causes a temporary outage of an entire business is usually considered a non-tolerable option, regardless of its speed of operation.
Because of the gravity of such incorrect stores, it has been necessary to adopt more stringent testing methods, involving more calendar time and CPU usage, to increase assurance that most errors have been removed from application codes that are executed on behalf of transactions.
An obvious way to prevent such program failures is to isolate the different programs and data bases from each other in their system, so that one program cannot access any other program or data base in the system. This isolation should be done such that any store outside the anticipated scope of a particular transaction will be caught by the processor when it is attempted, not allowing the incorrect store to occur. The incorrect store can then be reported to the operating system which notifies the base subsystem controlling the family of transaction applications that the transaction should be aborted. An error message can result in the timely correction of the faulty program. The subsystem remains in full operation controlling the other transactions underway. Only one transaction is aborted, the installation is notified, the incorrect store is avoided, and no other transaction or data is affected in anyway.
A prior protection technique for programs executing with virtual addresses is to isolate different programs and their data in different address spaces. That is, a program executing in one address space cannot cause an incorrect store effecting the programs and data in any other address space.
The prior art discloses two types of virtual address spaces, each of which represents a sequence of virtual addresses and has the isolation characteristic. They are: 1. A program address space (herein called a "program space"); and 2. A data address space (herein called a "data space"). Both types of address spaces are specified in a computer system by an ASN-second-table-entry (ASTE).
Each type of address space is defined in a computer system by a "translation table designation" (TTD) which contains a "translation table origin" (TTO) and a "translation table length" (TTL). The TTO locates the translation table in system main memory, and the TTL specifies the length of the translation table by its number of entries. In the System/370 and ESA/390 architectures, which use a two level translation operation, the TTD containing a TTO and TTL are respectively represented as the STD (segment table designation) containing the STO (segment table origin) and the STL (segment table length). In a computer architecture using a single level translation operation, the TTD, TTO and TTL may be respectively represented by a PTD (page table designation) containing a PTO (page table origin) and a PTL (page table length).
In the ESA/390 architecture, each program space also has a unique ASN (address space number) assigned to it, whereas a data space does not have an assigned ASN. A program space contains executable code, and may also contain data. A data space only contains data, and does not contain executable code, but unexecutable code may be included as data. The architecture and operating system prevent instructions from being executed in a data space.
Complex procedures are involved when a non-supervisory program must switch from one program address space to another program address space to call another program. One technique is to use the ESA/390 "program call with space switching" (PC-ss) instruction that has a PC number as an operand. The PC number must first go through a PC number translation for being translated to an ASN (address space number). Then the PC instruction goes through ASN translation for being translated to an STD (segment table designation). The multiple translations of the complete PC instruction go through the numerous different types of authority checks to assure the integrity of the data in the system.
The PC-ss was disclosed and claimed in U.S. patent application Ser. No. 07/732,936 (PO984011) entitled "Linkage Mechanism for Program Isolation" filed Jul. 19, 1991 which is a continuation of U.S. application Ser. No. 07/154,733 filed Feb. 10, 1988 which are assigned to the same assignee as the subject application. The entire contents of application Ser. Nos. 07/732,936 and 07/154,733 are incorporated by reference into the subject application.
The complete PC instruction does not use ART (access register translation), which is only used for data accesses in the ESA/390 architecture. The ART process translates an ALET in an access register (AR) to an STD.
Both the PC translation and ART translation processes use an ASN second table entry (ASTE) each of which contains an STD currently recognized by the computer system. The ART process does not use any ASN to locate its accessed ASTE. An ASTE used by the ART process is called a "psudo-ASTE" if it is not designated by an ASN, which is the case when it represents a data address space. Any ASN designating an ASTE is only used for ASN translation, which is done by program call (PC) and related types of instructions, and the LASP (load address space parameters) instruction.
This invention substitutes a modified ART type of translation for ASN translation when making a program call within a family group of address spaces. The modified ART translation process is much less involved than the complete PC translation process by taking advantage of the relationship between the subspace and its basespace in the group to eliminate most of the authority checks used by the complete PC instruction. Nevertheless, the PC authority checks are still required, depended upon, and done when the family group is initially dispatched or when control is transferred to a program space outside the family, or is returned to the family from a program space outside the family group. This invention eliminates having to repeat all of the authority checks after the dispatch process for each time an address space is switched within a group.
Another way to isolate programs and data in storage is to use storage key protection, which is assignable to 4 KB blocks in real or absolute main storage. Only a limited number of storage keys are available (e.g. 16 keys). The isolation between storage blocks assigned different storage keys can require very high key-management overhead involving supervisory (privileged program) control to switch a problem-state program request for a key switching from one storage block having one storage key to another block having another storage key. (Only the supervisory key, key 0, has access to other key areas without performing specific PSW access key management. However, isolation between the different key storage areas is lost while the supervisory key is being used, so that it cannot be used by problem state application programs).
For example, if non-supervisory keys are assigned to first and second blocks, and a program in the second block needs to access data in the first block, the key to the first block may be assigned temporarily to the program in the second key block to allow it to access the first key block. Thus, a significant amount of system overhead is required to assign and unassign the key to that program, involving an interruption in the program's operation while an operating system supervisory program changes the key assignments. Storage key assignment operations are so security sensitive that they generally are done only by the main operating system program. Accordingly, storage key switching may be useful only where very little or no program switching, or communication, between blocks assigned different keys, is required.
A program may be authorized to use more than one access key, but it then must manage the switching of the PSW access key values by use of an instruction in ESA/390 such as Set PSW Key From Address (SPKA).
Key protection requires the initialization of the access and storage keys involved, as well as special storage key hardware arrays to store the keys for all 4 KB blocks in the memory. A program's access key is specified by a field in the PSW (program status word) under which the program is executed. A storage key is associated with each block of real storage. Key protection can permit multiple levels of access authority to be used within a single program. The program may be given the capability to access more than one key. This capability is provided by a control register field called the PKM (program key mask), initialized by an operating system for the task to be executed. However, in general, only one access key value may be in use at any time. (A small set of instructions exist in the ESA/390 architecture for moving data from one location in storage to another which allow a separate protection key for each operand. One key is the PSW key; the other key must be authorized by the PKM in problem state, or implicitly allowed by executing in supervisor state.)
Key protection may apply to programs executing in the same address space or in another address space. Thus, key protection can complement address space protection, since these different forms of isolation have different characteristics.
The use of a "public storage key" (PSK) provides a partial solution to addressing isolation within a related group (family) of programs and data by eliminating the need for key management under limited circumstances. The public storage key provides unidirectional access for programs to storage blocks assigned the PSK. That is, the use of the PSK can protect all blocks of storage assigned any key, other than the PSK, from wild stores caused by programs executing under the access authority of the PSK, while allowing public access by all programs assigned any key to storage blocks assigned the PSK. The PSK is disclosed and claimed in U.S. patent application Ser. No. 07/710,875 (PO991016) entitled "Storage Protection Utilizing Public Key Control" filed Jun. 6, 1991 which is assigned to the same assignee as the present application, and is incorporated herein by reference.
An advantage in using the PSK is that it can eliminate the need for key management programming in certain situations. Without any key switching control, the PSK can protect data and programs in storage blocks assigned the supervisory key or any non-supervisory key from being changed by programs executing under the PSK mode in the PSW. The storage they access is in blocks assigned PSK. At the same time, the PSK storage blocks may be changed by any program executing with any key value, including the PSK value. This is particularly useful for any family of programs and data having a base program which must have access to all programs and data in the family and which performs services for all members of the family, in particular those that require interactions with the operating family, in particular those that require interactions with the operating system, but there the base program needs to be protected from wild stores caused by any other non-base program.
For example, with a set of protect keys 0-15, the public storage key may have key value 9, the supervisory key may have key value 0, and the non-supervisory keys may have key values 1-8 and 10-15, for a total of 16 protect keys. Also, each of the storage protect keys 0-15 may have an associated fetch protect flag bit (FP), reference bit (R) and a change bit (C). Any protect key can be used as an access key located in the PSW (program status word) of a program, or as a storage protect key located in a storage array with an entry associated with each respective 4 KB block in a computer's main storage with that block's protection key.
The operating rules are that any non-supervisory key (1-8 and 10-15) user can access any public key (9) storage block. But no public key (9) user can store (or fetch if fetch protection is on) into any storage block protected by a supervisory key (key 0) or by an non-supervisory storage key (keys 1-8 and 10.varies.15).
Thus, a program executing with public access key 9 can only store into a block having PSK 9, regardless of the setting of the FP bit in the storage key. But fetching by a program having public access key 9 is controlled by the FP bit setting: If FP is 1 for any storage key, fetching is only permitted if equality exists (which restricts key 9 programs to accessing only storage blocks assigned PSK 9). But if FP is 0 in the storage key, fetching is permitted without equality (which allows public key 9 programs to access storage blocks assigned any storage key).
Programs assigned any non-supervisory key (1-8 and 10-15) or the supervisory key 0 can store or fetch into any PSK block (key 9) without equality, regardless of the state of the FP bit for the PSK block.
Nevertheless, highly used families of programs exist which run in a single address space without any isolation protection (even though the PC and related instructions and storage protection keys have been available) in order to obtain the fastest execution speed for such programs. Catastrophic data-integrity failures occasionally occur in such programs due to the lack of isolation between programs and data, which can exact a heavy price on businesses dependent on continuous and uninterrupted operation by such programs and data. Further, when data integrity violations occur, they usually are not found at the instant of occurrence, but are discovered later when they are noticed or cause erroneous results sometime in the future.
The PSK provided a means to address part of the isolation requirement. It allowed separation between the application programs and the base subsystem under whose control they execute, and on which they depend for services. The subject invention extends the isolation of the application code modules and data, protecting each one from all others. In the application of this invention to use virtual addressability to isolate each transaction in execution from all others, the PSK remains part of the total system solution by protecting the subsystem itself from all transactions, while allowing high performance direct access by it to the code and data of all transactions in performing its services.